Mehrfacheinträgein Tabelle Korrigieren

Hallo,
in eine Warenwirtschaftsanwendung (lx-office) mit PostgreSQL als
Datenbank gibt es eine Tabelle 'orderitems' mit folgendem Aufbau
Tabelle »public.orderitems=C2=
=AB
Spalte | Typ |
Attribute =20 =20=
=20
--------------------+-----------------------------+--------- ---------------=
-------------------------------
trans_id | integer |=20
parts_id | integer |=20
description | text |=20
qty | real |=20
sellprice | numeric(15,5) |=20
discount | real |=20
project_id | integer |=20
reqdate | date |=20
ship | real |=20
serialnumber | text |=20
id | integer | Vorgabewert
nextval(('orderitemsid'::text)::regclass)
itime | timestamp without time zone | Vorgabewert now()
mtime | timestamp without time zone |=20
pricegroup_id | integer |=20
ordnumber | text |=20
transdate | text |=20
cusordnumber | text |=20
unit | character varying(20) |=20
base_qty | real |=20
subtotal | boolean | Vorgabewert false
longdescription | text |=20
marge_total | numeric(15,5) |=20
marge_percent | numeric(15,5) |=20
lastcost | numeric(15,5) |=20
price_factor_id | integer |=20
price_factor | numeric(15,5) | Vorgabewert 1
marge_price_factor | numeric(15,5) | Vorgabewert 1
Indexe:
"orderitems_id_key" btree (id)
"orderitems_trans_id_key" btree (trans_id)
Fremdschlüssel-Constraints:
"$1" FOREIGN KEY (parts_id) REFERENCES parts(id)

Bei einer anstehenden Programmaktualisierung soll diese u.a. Tabelle
indexiert werden.
Die dazugehörige SQL-Anweisung meldet Fehler, mit dem Hinweis, das
Datensätze doppelt in dieser Tabelle vorhanden sind.
Meine händische Überprüfung zeigte mir, das Datensätze =
mehrfach, also 2,
3 bis 6 fach auftreten.
Diese sind in allen Spalten genau gleich, als auch in 'itime' und
'mtime'.
Wie diese entstanden sind ist derzeit nicht nachvollziehbar.

Frage:
Mit welcher Anweisung kann man diese Tabelle bereinigen, so dass jeder
Datensatz nur einmal auftaucht?

Ich bitte um eure Unterstützung.

Gruß


--=20
Armin Barth


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: Me

Armin Barth wrote:

> Hallo,
> in eine Warenwirtschaftsanwendung (lx-office) mit PostgreSQL als
> Datenbank gibt es eine Tabelle 'orderitems' mit folgendem Aufbau
> Tabelle =BBpublic.orderitems=AB
> Spalte | Typ |
> Attribute =20
> --------------------+-----------------------------+--------- -----------=
-----------------------------------
> trans_id | integer |=20
> parts_id | integer |=20
> description | text |=20
> qty | real |=20
> sellprice | numeric(15,5) |=20
> discount | real |=20
> project_id | integer |=20
> reqdate | date |=20
> ship | real |=20
> serialnumber | text |=20
> id | integer | Vorgabewert
> nextval(('orderitemsid'::text)::regclass)
> itime | timestamp without time zone | Vorgabewert now()
> mtime | timestamp without time zone |=20
> pricegroup_id | integer |=20
> ordnumber | text |=20
> transdate | text |=20
> cusordnumber | text |=20
> unit | character varying(20) |=20
> base_qty | real |=20
> subtotal | boolean | Vorgabewert false
> longdescription | text |=20
> marge_total | numeric(15,5) |=20
> marge_percent | numeric(15,5) |=20
> lastcost | numeric(15,5) |=20
> price_factor_id | integer |=20
> price_factor | numeric(15,5) | Vorgabewert 1
> marge_price_factor | numeric(15,5) | Vorgabewert 1
> Indexe:
> "orderitems_id_key" btree (id)
> "orderitems_trans_id_key" btree (trans_id)
> Fremdschlüssel-Constraints:
> "$1" FOREIGN KEY (parts_id) REFERENCES parts(id)
>=20
> Bei einer anstehenden Programmaktualisierung soll diese u.a. Tabelle
> indexiert werden.
> Die dazugehörige SQL-Anweisung meldet Fehler, mit dem Hinweis, das
> Datensätze doppelt in dieser Tabelle vorhanden sind.
> Meine händische Überprüfung zeigte mir, das Datensätze mehrfach=
, also 2,
> 3 bis 6 fach auftreten.
> Diese sind in allen Spalten genau gleich, als auch in 'itime' und
> 'mtime'.
> Wie diese entstanden sind ist derzeit nicht nachvollziehbar.
>=20
> Frage:
> Mit welcher Anweisung kann man diese Tabelle bereinigen, so dass jeder
> Datensatz nur einmal auftaucht?
>=20
> Ich bitte um eure Unterstützung.

Als erstes solltest Du die Macher der Software kräftig treten.

Zu Deiner Frage:

test=3D# select * from bla;
a | b | c
---+---+---
1 | 1 | 1
1 | 2 | 3
1 | 2 | 2
1 | 3 | 4
1 | 2 | 3
1 | 1 | 1
(6 Zeilen)

Zeit: 0,165 ms
test=3D*# select distinct on (a,b,c) ctid, a,b,c from bla;
ctid | a | b | c
-------+---+---+---
(0,1) | 1 | 1 | 1
(0,3) | 1 | 2 | 2
(0,2) | 1 | 2 | 3
(0,4) | 1 | 3 | 4
(4 Zeilen)

Zeit: 0,286 ms
test=3D*# delete from bla where (ctid, a,b,c) not in (select distinct on
(a,b,c) ctid, a,b,c from bla);
DELETE 2
Zeit: 33,910 ms
test=3D*# select * from bla;
a | b | c
---+---+---
1 | 1 | 1
1 | 2 | 3
1 | 2 | 2
1 | 3 | 4
(4 Zeilen)

Zeit: 0,220 ms



Andreas
--=20
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889=
°

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: MehrfacheinträgeinTabelle Korrigieren

Hallo Andreas,
danke für deine schnelle Antwort.

>=20
> Als erstes solltest Du die Macher der Software kräftig treten.
>=20
Habe ich schon versucht, aber die schütteln sich nur und behaupten es
wäre ein Anwenderfehler.
Wie auch immer.
Die Lösung ist wichtig.
Also mit der Test-Tabelle habe ich es gerade versucht - klapp wunder
bar.
Nochmals DANKE !

> Zu Deiner Frage:
>=20
> test=3D# select * from bla;
> a | b | c
> ---+---+---
> 1 | 1 | 1
> 1 | 2 | 3
> 1 | 2 | 2
> 1 | 3 | 4
> 1 | 2 | 3
> 1 | 1 | 1
> (6 Zeilen)
>=20
> Zeit: 0,165 ms
> test=3D*# select distinct on (a,b,c) ctid, a,b,c from bla;
> ctid | a | b | c
> -------+---+---+---
> (0,1) | 1 | 1 | 1
> (0,3) | 1 | 2 | 2
> (0,2) | 1 | 2 | 3
> (0,4) | 1 | 3 | 4
> (4 Zeilen)
>=20

Das mit dem 'ctid' ist mir neu=20
Was ist das -- finde ich in meinem Postgresql-Buch nicht.
Ist das nur eine temporärer Index?
Denn bei 'SELECT * FROM bla;' taucht er nicht auf.



> Zeit: 0,286 ms
> test=3D*# delete from bla where (ctid, a,b,c) not in (select distinct on
> (a,b,c) ctid, a,b,c from bla);
> DELETE 2
> Zeit: 33,910 ms
> test=3D*# select * from bla;
> a | b | c
> ---+---+---
> 1 | 1 | 1
> 1 | 2 | 3
> 1 | 2 | 2
> 1 | 3 | 4
> (4 Zeilen)
>=20
> Zeit: 0,220 ms
>=20
>=20
>=20
> Andreas
> --=20
> Really, I'm not out to destroy Microsoft. That will just be a completely
> unintentional side effect. (Linus Torvalds)
> "If I was god, I would recompile penguin with --enable-fly." (unknown)
> Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56=
889°
>=20


Ich melde mich noch mal, wenn ich es mit der Originaltabelle versucht
habe.
Gruß
Armin
--=20
Armin Barth


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

AW: [pgsql-de-allgemein] Mehrfacheinträge in Tabelle Korrigieren

aHR0cDovL3d3dy5wb3N0Z3Jlc3FsLm9yZy9kb2NzLzguNC9zdGF0aWMvZGRs
LXN5c3RlbS1jb2x1bW5zLmh0bWwNCg0KR3J1c3MNCg0KLS0tLS1VcnNwcsO8
bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBwZ3NxbC1kZS1hbGxnZW1l
aW4tb3duZXJAcG9zdGdyZXNxbC5vcmcgW21haWx0bzpwZ3NxbC1kZS1hbGxn
ZW1laW4tb3duZXJAcG9zdGdyZXNxbC5vcmddIEltIEF1ZnRyYWcgdm9uIEFy
bWluIEJhcnRoDQpHZXNlbmRldDogTWl0dHdvY2gsIDI2LiBKYW51YXIgMjAx
MSAwNzozMw0KQW46IEFuZHJlYXMgS3JldHNjaG1lcg0KQ2M6IHBnc3FsLWRl
LWFsbGdlbWVpbkBwb3N0Z3Jlc3FsLm9yZw0KQmV0cmVmZjogUmU6IFtwZ3Nx
bC1kZS1hbGxnZW1laW5dIE1laHJmYWNoZWludHLDpGdlIGluIFRhYmVsbGUg
S29ycmlnaWVyZW4NCg0KSGFsbG8gQW5kcmVhcywNCmRhbmtlIGbDvHIgZGVp
bmUgc2NobmVsbGUgQW50d29ydC4NCg0KPiANCj4gQWxzIGVyc3RlcyBzb2xs
dGVzdCBEdSBkaWUgTWFjaGVyIGRlciBTb2Z0d2FyZSBrcsOkZnRpZyB0cmV0
ZW4uDQo+IA0KSGFiZSBpY2ggc2Nob24gdmVyc3VjaHQsIGFiZXIgZGllIHNj
aMO8dHRlbG4gc2ljaCBudXIgdW5kIGJlaGF1cHRlbiBlcw0Kd8OkcmUgZWlu
IEFud2VuZGVyZmVobGVyLg0KV2llIGF1Y2ggaW1tZXIuDQpEaWUgTMO2c3Vu
ZyBpc3Qgd2ljaHRpZy4NCkFsc28gbWl0IGRlciBUZXN0LVRhYmVsbGUgaGFi
ZSBpY2ggZXMgZ2VyYWRlIHZlcnN1Y2h0IC0ga2xhcHAgd3VuZGVyDQpiYXIu
DQpOb2NobWFscyBEQU5LRSAhDQoNCj4gWnUgRGVpbmVyIEZyYWdlOg0KPiAN
Cj4gdGVzdD0jIHNlbGVjdCAqIGZyb20gYmxhOw0KPiAgYSB8IGIgfCBjDQo+
IC0tLSstLS0rLS0tDQo+ICAxIHwgMSB8IDENCj4gIDEgfCAyIHwgMw0KPiAg
MSB8IDIgfCAyDQo+ICAxIHwgMyB8IDQNCj4gIDEgfCAyIHwgMw0KPiAgMSB8
IDEgfCAxDQo+ICg2IFplaWxlbikNCj4gDQo+IFplaXQ6IDAsMTY1IG1zDQo+
IHRlc3Q9KiMgc2VsZWN0IGRpc3RpbmN0IG9uIChhLGIsYykgY3RpZCwgYSxi
LGMgZnJvbSBibGE7DQo+ICBjdGlkICB8IGEgfCBiIHwgYw0KPiAtLS0tLS0t
Ky0tLSstLS0rLS0tDQo+ICAoMCwxKSB8IDEgfCAxIHwgMQ0KPiAgKDAsMykg
fCAxIHwgMiB8IDINCj4gICgwLDIpIHwgMSB8IDIgfCAzDQo+ICAoMCw0KSB8
IDEgfCAzIHwgNA0KPiAoNCBaZWlsZW4pDQo+IA0KDQpEYXMgbWl0IGRlbSAn
Y3RpZCcgaXN0IG1pciBuZXUgDQpXYXMgaXN0IGRhcyAtLSBmaW5kZSBpY2gg
aW4gbWVpbmVtIFBvc3RncmVzcWwtQnVjaCBuaWNodC4NCklzdCBkYXMgbnVy
IGVpbmUgdGVtcG9yw6RyZXIgSW5kZXg/DQpEZW5uIGJlaSAnU0VMRUNUICog
RlJPTSBibGE7JyB0YXVjaHQgZXIgbmljaHQgYXVmLg0KDQoNCg0KPiBaZWl0
OiAwLDI4NiBtcw0KPiB0ZXN0PSojIGRlbGV0ZSBmcm9tIGJsYSB3aGVyZSAo
Y3RpZCwgYSxiLGMpIG5vdCBpbiAoc2VsZWN0IGRpc3RpbmN0IG9uDQo+IChh
LGIsYykgY3RpZCwgYSxiLGMgZnJvbSBibGEpOw0KPiBERUxFVEUgMg0KPiBa
ZWl0OiAzMyw5MTAgbXMNCj4gdGVzdD0qIyBzZWxlY3QgKiBmcm9tIGJsYTsN
Cj4gIGEgfCBiIHwgYw0KPiAtLS0rLS0tKy0tLQ0KPiAgMSB8IDEgfCAxDQo+
ICAxIHwgMiB8IDMNCj4gIDEgfCAyIHwgMg0KPiAgMSB8IDMgfCA0DQo+ICg0
IFplaWxlbikNCj4gDQo+IFplaXQ6IDAsMjIwIG1zDQo+IA0KPiANCj4gDQo+
IEFuZHJlYXMNCj4gLS0gDQo+IFJlYWxseSwgSSdtIG5vdCBvdXQgdG8gZGVz
dHJveSBNaWNyb3NvZnQuIFRoYXQgd2lsbCBqdXN0IGJlIGEgY29tcGxldGVs
eQ0KPiB1bmludGVudGlvbmFsIHNpZGUgZWZmZWN0LiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIChMaW51cyBUb3J2YWxkcykNCj4gIklmIEkgd2Fz
IGdvZCwgSSB3b3VsZCByZWNvbXBpbGUgcGVuZ3VpbiB3aXRoIC0tZW5hYmxl
LWZseS4iICAgKHVua25vd24pDQo+IEthdWZiYWNoLCBTYXhvbnksIEdlcm1h
bnksIEV1cm9wZS4gICAgICAgICAgICAgIE4gNTEuMDUwODLCsCwgRSAxMy41
Njg4OcKwDQo+IA0KDQoNCkljaCBtZWxkZSBtaWNoIG5vY2ggbWFsLCB3ZW5u
IGljaCBlcyBtaXQgZGVyIE9yaWdpbmFsdGFiZWxsZSB2ZXJzdWNodA0KaGFi
ZS4NCkdydcOfDQpBcm1pbg0KLS0gDQpBcm1pbiBCYXJ0aCA8YXJtaW4uYmFy
dGhAcHVtcGVuLWJhcnRoLmRlPg0KDQoNCi0tIA0KU2VudCB2aWEgcGdzcWwt
ZGUtYWxsZ2VtZWluIG1haWxpbmcgbGlzdCAocGdzcWwtZGUtYWxsZ2VtZWlu
QHBvc3RncmVzcWwub3JnKQ0KVG8gbWFrZSBjaGFuZ2VzIHRvIHlvdXIgc3Vi
c2NyaXB0aW9uOg0KaHR0cDovL3d3dy5wb3N0Z3Jlc3FsLm9yZy9tYWlscHJl
Zi9wZ3NxbC1kZS1hbGxnZW1laW4NCgotLSAKU2VudCB2aWEgcGdzcWwtZGUt
YWxsZ2VtZWluIG1haWxpbmcgbGlzdCAocGdzcWwtZGUtYWxsZ2VtZWluQHBv
c3RncmVzcWwub3JnKQpUbyBtYWtlIGNoYW5nZXMgdG8geW91ciBzdWJzY3Jp
cHRpb246Cmh0dHA6Ly93d3cucG9zdGdyZXNxbC5vcmcvbWFpbHByZWYvcGdz
cWwtZGUtYWxsZ2VtZWluCg==

Re: [pgsql-de-allgemein] Mehrfacheinträge in Tabell

--0016e65b64f21aa5d8049abbe344
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hallo Armin!

>
> > Als erstes solltest Du die Macher der Software kräftig treten.
> >
> Habe ich schon versucht, aber die schütteln sich nur und behaupten e=
s wäre
> ein Anwenderfehler.
> Wie auch immer.
> Die Lösung ist wichtig.


ich bezweifle, daß Treten hilft :) Du hast recht, die Lösung ist =
JETZT
wichtig.

Mittelfristig KANN dies kein Anwenderfehler alleine sein: d.h., vermutlich
hat der Softwaremacher recht, daß hier die Anwender böses eingetr=
agen haben.

ABER die Datenbanktechnik ernstzunehmender Datenbanken kann das seit mehr
als einem Jahrzehnt zuverlässig verhindern:
über die entsprechenden Spalten ein UNIQUE-Constraint legen. Wenn dann
irgendwer doppelte Einträge reinmachen will (Anwender, Software), wird=
das
verhindert. Einzige Probleme sind dann noch kosmische Strahlen und
wear-and-tear der Datenträger.
Da Du ja ADMIN-Zugriff auf die DB hast, solltest Du (nach REparatur) ein
solches Constraint einrichten:

http://www.postgresql.org/docs/8.4/static/ddl-constraints.ht ml
5.3.3. Unique Constraints
(geht natürlich auch mit Alter Table)

Gruß

Harald



> --

Harald Armin Massa www.2ndQuadrant.com
PostgreSQL Training, Services and Support

2ndQuadrant Deutschland GmbH
GF: Harald Armin Massa

--0016e65b64f21aa5d8049abbe344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hallo Armin!

Re: MehrfacheinträgeinTabelle Korrigieren

Hallo Andreas,
es hat auch mit der Originaltabelle funktioniert.
(mit Sicherheitskopie vorher)
669 Datensätze sind auf 219 zusammengeschmolzen.

Leider mag die Umstellungs-SQL-Anweisung von Lx-Office
mein Tabelle immer noch nicht, da angeblich immer noch
doppelte Werte vorhanden sind.
Ich suche weiter und werde mal die SQL-Anweisung inspizieren,
wo nach diese die Unterscheidungsmerkmale trifft.

Sicher wäre ein PK hier sinnvoller gewesen.
Das soll ja nun offensichtlich beim Update nachgeholt werden.=20

Offen sichtlich sind es folgende Datensätze, die sich jedoch in der
Spalte 'description' und 'price' unterscheiden.

ctid | trans_id | parts_id | id | itime |
mtime
--------+----------+----------+-----+----------------------- -----+---------=
-------------------
(1,29) | 3322 | 3311 | 10 | 2008-01-07 10:42:24.546097 |
2008-08-13 08:05:26.049818
(5,12) | 3322 | 3311 | 10 | 2008-01-07 10:42:24.546097 |
2008-08-20 06:57:03.763137
(1,30) | 3322 | 3316 | 11 | 2008-01-07 10:42:24.546097 |
2008-08-13 08:05:26.049818
(0,11) | 3322 | 3316 | 11 | 2008-01-07 10:42:24.546097 |
2008-08-20 06:57:03.763137
(1,31) | 3322 | 3318 | 12 | 2008-01-07 10:42:24.546097 |
2008-08-13 08:05:26.049818
(2,24) | 3322 | 3318 | 12 | 2008-01-07 10:42:24.546097 |
2008-08-20 06:57:03.763137


Hier wird mit als Anwender wohl nichts anders übrig bleiben, als mich =
zu
entscheiden, welchen der beiden Dubletten ich weiter verwenden will.

Oder?


> >=20
> >>
> >> Als erstes solltest Du die Macher der Software kräftig treten.
> >>
> > Habe ich schon versucht, aber die schütteln sich nur und behaupten=
es
> > wäre ein Anwenderfehler.
> > Wie auch immer.
>=20
> Es ist ein Designfehler, wenn da kein PK ist und daher Dubletten auftauch=
en.
>=20
> > Die Lösung ist wichtig.
>=20
> ACK.
> >=20
> > Das mit dem 'ctid' ist mir neu=20
> > Was ist das -- finde ich in meinem Postgresql-Buch nicht.
> > Ist das nur eine temporärer Index?
>=20
> Warum schaust nicht mal in die offizielle Online-Doku und nutzt deren
> Suchfunktion?
>=20
> the current tuple ID (CTID). This is a system column containing the file
> block number and position in the block for the row.
>=20
Danke für den Hinweis. Mit den System Columns hatte ich bisher nichts =
zu
tun. Nun weiß ich mehr.
>=20
>=20
> > Denn bei 'SELECT * FROM bla;' taucht er nicht auf.
>=20
> Ja, wenn Du nicht ctid,* abfragst, bekommst die Spalte auch nicht zu
> sehen. Sie ist aber in jeder Tabelle vorhanden, und noch weitere. Die
> Doku kennt sie alle ...
>=20
> >=20
> > Ich melde mich noch mal, wenn ich es mit der Originaltabelle versucht
> > habe.
>=20
> Ich werf da mal noch ein Reizwort in den Raum: Backup.
>=20
s.o. -- habe ich berücksichtig
>=20
> Btw.: wir hosten hier auch PostgreSQL ;-)
>=20


--=20
Armin Barth


--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein